Voice over IP (VoIP) encodes speech as a series of small packets that are sent at regular intervals over a network. The H.323 G.723 codec (coder/decoder) at a sending telephone creates packets of 65 to 69 bytes, and sends them out over a network (e.g., the Internet) every 30 to 120 milliseconds. Other codecs use similar packet sizes and intervals. Packets must arrive at the receiving telephone on a regular basis and with low overall delay, or the received audio suffers.
There are three primary constraints on the series of packets carrying a voice call in order to recreate an acceptable audio stream at the receiving telephone: delay, jitter, and lost packets. Delay corresponds to the time delay from the sending telephone to the receiving telephone. 150 milliseconds or less is typically deemed to be an acceptable delay. Jitter corresponds to the variation in the delay of arriving packets. High jitter sounds like echo, which is undesirable. 30 milliseconds or less jitter is typically deemed to be acceptable. Lost packets correspond to the percentage of packets that are lost in transit. A lost packet results in silence played for its time slot at the receiving telephone. Less than 1% packet is typically deemed to be acceptable.
A stable and predictive network is desired in order to carry voice call packets. The routers and switches utilized in voice call paths must be able to identify voice packets and queue them ahead of packets that have less stringent requirements, thus reducing both jitter and delay. The network also should be reliable, so that packets are infrequently lost or damaged.
Identifying bad VoIP calls is conventionally performed by either of two ways: a) Synthetic testing that creates simulated voice calls, or b) Collecting and sorting delay, jitter, and dropped packet statistics from VoIP telephones. Once a bad call path has been identified, the faulty or misconfigured router, switch or network interface must be identified and corrected, or otherwise call problems will persist on the network.
VoIP analysis is a new market, and not many tools exist to aid a network administrator. The current set of tools are primarily focused on end-to-end analysis of active tests or of Call Data Records (CDRs) reported by telephone systems, or both. These two methods rely on detecting the presence of delay, jitter, or dropped packets, either from test data reported by probes or from CDRs after the actual calls are complete.
A probe is a small device that is a combination of hardware and software, or it can correspond to a completely software component that is loaded onto an existing computer or PC connected to a network. Probes often are controlled by a central test controller that is a dedicated computer that coordinates the tests between probes and collects and reports the results of the tests.
CDR data can be processed to identify those calls that have the worst call characteristics (e.g., high delay, high jitter, or high numbers of dropped packets). Unfortunately, that data, while useful for identifying that a problem exists, is not very useful for troubleshooting the problem and for identifying the cause of the problem.
Active test data, reported by probes that generate simulated calls, can provide more detail about problems it encounters because it can adapt to the presence of bad call characteristics and do additional testing on a link-by-link basis. Active testing relies on one or more sending and receiving systems to generate synthetic (artificial) voice calls to measure network characteristics that contribute to poor call quality. Typical characteristics are delay, jitter and dropped packets. Active testing can be used prior to implementing a VoIP system as a way to validate that the network is capable of handling voice calls with acceptable performance. It can also be configured to perform testing at regular, periodic intervals so as to detect problems that may occur at specific times of the day.
Cisco Systems' Service Assurance Agent™ is a conventional active testing mechanism. In addition to basic network performance data of a simulated call, it provides data on the routers that were traversed in the path between two test nodes. The data is similar to that provided by a Traceroute program. Once the routers in the path are identified by the active testing system, any switches that interconnect the routers can also be identified and the layer-2 connectivity between routers (which are layer-3 devices).
For active testing systems, the router hop-by-hop testing is limited to using Internet Control Message Protocol (ICMP) Echo Request and Echo Reply packets to measure network timing and throughput, whereby this level of testing is typically insufficient for identifying many of the problems that affect VoIP networks.
Thus, there is a need for a diagnostic tool to be utilized for VoIP networks.